Pas exactement. Il était en train de microbenchmarker autre chose que le temps de connexion de SSH, et il était dérangé par le fait que SSH occupait trop de CPU et il voulait retirer le bruit de fond qui polluait son benchmark :
I didn't even notice it during logging in with ssh or such. I was doing some micro-benchmarking at the time and was looking to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd. Which showed lots of cpu time in code with perf unable to attribute it to a symbol, with the dso showing as liblzma. Got suspicious.
-- https://lwn.net/Articles/967180/#CommAnchor967194
Le temps de connexion qui met plus ou moins 500ms à échouer est simplement l’exemple le plus simple pour reproduire le problème.
J’ai aussi vu d’autres personne utiliser le temps d’exécution pour supposer une désactivation éventuelle de la porte-dérobée (il y aurait une variable d’environnement cachée prévue à cet effet, probablement pour que les commanditaires puissent continuer à utiliser des distributions mainstream en désactivant pour eux-même la porte dérobée): https://piaille.fr/@zeno/112185928685603910
L’idée que la porte dérobée aurait été découverte par « un héro qui prend son boulot tellement au sérieux qu’il a investigué une latence de 500ms pour se connecter » ou « un nerd autiste maniaque qui a un seul de tolérance à la patience inférieure à 500ms » (comme j’ai pu lire dans certains commentaires en divers endroits), pour le glorifier ou pour se moquer de lui, c’est typiquement du mythe construit sur du vrai enjolivé et romancé qu’on retrouvera dans le récit mythique d’une odyssée, une comédie musicale, ou un film hollywoodien « inspiré de faits réels ». Ce qui n’enlève rien à l’expertise du gars et à la reconnaissance qu’on peut avoir envers lui.
Mais cela signifie aussi que la probabilité était encore plus rare de repérer la porte dérobée, car à mon avis détecter une latence à l’usage a plus de chance d’être remarquée que s’inquiéter de quelque sauts d’usage de SSH en arrière plan que tu ne constate pas physiquement avec tes propres sens. J’ai vu des utilisateurs passer d’un état calme à avoir le sang qui bout instantanément si une appli se fige quelque millisecondes…
On retiendra aussi que la porte dérobée a été révélée involontairement par un canal auxilliaire (side channel).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: un salarié de chez M$ 'sauve Linux'
Posté par Thomas Debesse (site web personnel) . En réponse à la dépêche XZ et liblzma: Faille de sécurité volontairement introduite depuis au moins deux mois. Évalué à 10 (+12/-0). Dernière modification le 01 avril 2024 à 23:45.
Pas exactement. Il était en train de microbenchmarker autre chose que le temps de connexion de SSH, et il était dérangé par le fait que SSH occupait trop de CPU et il voulait retirer le bruit de fond qui polluait son benchmark :
Le temps de connexion qui met plus ou moins 500ms à échouer est simplement l’exemple le plus simple pour reproduire le problème.
J’ai aussi vu d’autres personne utiliser le temps d’exécution pour supposer une désactivation éventuelle de la porte-dérobée (il y aurait une variable d’environnement cachée prévue à cet effet, probablement pour que les commanditaires puissent continuer à utiliser des distributions mainstream en désactivant pour eux-même la porte dérobée): https://piaille.fr/@zeno/112185928685603910
L’idée que la porte dérobée aurait été découverte par « un héro qui prend son boulot tellement au sérieux qu’il a investigué une latence de 500ms pour se connecter » ou « un nerd autiste maniaque qui a un seul de tolérance à la patience inférieure à 500ms » (comme j’ai pu lire dans certains commentaires en divers endroits), pour le glorifier ou pour se moquer de lui, c’est typiquement du mythe construit sur du vrai enjolivé et romancé qu’on retrouvera dans le récit mythique d’une odyssée, une comédie musicale, ou un film hollywoodien « inspiré de faits réels ». Ce qui n’enlève rien à l’expertise du gars et à la reconnaissance qu’on peut avoir envers lui.
Mais cela signifie aussi que la probabilité était encore plus rare de repérer la porte dérobée, car à mon avis détecter une latence à l’usage a plus de chance d’être remarquée que s’inquiéter de quelque sauts d’usage de SSH en arrière plan que tu ne constate pas physiquement avec tes propres sens. J’ai vu des utilisateurs passer d’un état calme à avoir le sang qui bout instantanément si une appli se fige quelque millisecondes…
On retiendra aussi que la porte dérobée a été révélée involontairement par un canal auxilliaire (side channel).
ce commentaire est sous licence cc by 4 et précédentes